Skip to content

Extend profiler toolbar item #135

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Apr 30, 2017
Merged

Extend profiler toolbar item #135

merged 4 commits into from
Apr 30, 2017

Conversation

chr-hertel
Copy link
Contributor

@chr-hertel chr-hertel commented Mar 17, 2017

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Related tickets -
Documentation -
License MIT

Depends on stopwatch plugin PR

What's in this PR?

Extended profiler toolbar item to display more details and duration

bildschirmfoto 2017-03-17 um 17 47 31

@Nyholm Nyholm self-requested a review March 17, 2017 17:03
Copy link
Collaborator

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks very cool, thanks a lot! i tried to find where x-duration comes from, but don't find that in the php-http codebase.


$this->collector->addStack($stack);

return $next($request)->then(function (ResponseInterface $response) use ($stack) {
$stack->setResponse($this->formatter->formatResponse($response));
$stack->setResponseCode($response->getStatusCode());

if ($response->hasHeader('X-Duration')) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does the x-duration header come from?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, now i got it, this depends on php-http/stopwatch-plugin#3

Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. Thanks!

Is it ready for merge?

@dbu dbu changed the title Extend profiler toolbar item WIP: Extend profiler toolbar item Mar 20, 2017
@dbu
Copy link
Collaborator

dbu commented Mar 20, 2017

@Nyholm it depends on php-http/stopwatch-plugin#3 and we currently are trying to figure out how to track requests and responses in the plugin chain...

@fbourigault
Copy link
Contributor

fbourigault commented Mar 21, 2017

What do you thing about removing the stopwatch plugin from the profiled stacks and directly use the stopwatch component in the StackPlugin?

    public function handleRequest(RequestInterface $request, callable $next, callable $first)
    {
        $stack = new Stack(
            $this->client,
            $request->getMethod(),
            $request->getRequestTarget(),
            $this->formatter->formatRequest($request)
        );

        $this->collector->addStack($stack);
        $eventName = sprintf('%s %s', $request->getMethod(), $request->getUri()->__toString());
        $event = $this->stopwatch->start($eventName, 'php_http.request');
        return $next($request)->then(function (ResponseInterface $response) use ($stack, $event) {
            $stack->setResponse($this->formatter->formatResponse($response));
            $stack->setResponseCode($response->getStatusCode());
            
            $event->stop();
            $stack->setDuration($event->getDuration());

            return $response;
        }, function (Exception $exception) use ($stack) {
            $stack->setResponse($this->formatter->formatException($exception));
            $stack->setFailed(true);

            $event->stop();
            $stack->setDuration($event->getDuration());

            throw $exception;
        });
    }

Such implementation does not require changes neither in symfony nor in the stopwatch plugin :)

@chr-hertel
Copy link
Contributor Author

@fbourigault yes, would be an easy solution and more convincing than extending symfony's stopwatch. thanks :)
but IMO it's still a valid option to manipulate the response in stopwatch-plugin. we're just adding plugin related meta information to response.
@dbu @Nyholm let me know what your favorite choice is and i will adjust those PRs.

@dbu
Copy link
Collaborator

dbu commented Mar 22, 2017

i think using the stopwatch directly instead of the plugin sounds better to me. much less complicated and achieves the same functionality in a clean way. at that point we would not need the stopwatch plugin for the bundle at all anymore, right?

@fbourigault
Copy link
Contributor

@dbu
Copy link
Collaborator

dbu commented Mar 22, 2017

oh good. then we don't need to decide if it would be a BC break to change the dependency...

@chr-hertel
Copy link
Contributor Author

alright, great! :) i'll take care of this the next days

Copy link
Contributor

@fbourigault fbourigault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is what I did on my laptop: master...fbourigault:profile-client
This is a work in progress and I didn't tested how it operates with discovery.

$stack = new Stack(
$this->client,
$request->getMethod(),
$request->getRequestTarget(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't better to track the request target closer to the client? Plugins may change the target (BaseUrlPlugin). I have on my laptop something equivalent to improve the profiler display.


$this->collector->addStack($stack);

return $next($request)->then(function (ResponseInterface $response) use ($stack) {
$stack->setResponse($this->formatter->formatResponse($response));
$stack->setResponseCode($response->getStatusCode());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same happens here. Tracking close to the client avoid the ErrorPlugin to transform 4xx and 5xx errors to exceptions.

This was referenced Apr 1, 2017
@Nyholm Nyholm added this to the Version 1.5.0 milestone Apr 19, 2017
@Nyholm
Copy link
Member

Nyholm commented Apr 19, 2017

I've added this to the 1.5 milestone. Can you see why the tests are failing?

@fbourigault
Copy link
Contributor

Could you also rebase your branch to get thinks working with ProfileClient?

@chr-hertel
Copy link
Contributor Author

rebase is done and tests are not failing anymore. (honestly no clue what happened there.)

any ideas how to deal with the stopwatch-plugin? i think we need to disabled or even remove it because it interferes with the current implementation. but we could also stop using debug.stopwatch service in ProfileClient and instantiate a separate stopwatch.

@fbourigault
Copy link
Contributor

fbourigault commented Apr 23, 2017

About the stopwatch, I would remove the plugin and mesure time in the StackPlugin.

EDIT: to be more accurate, measuring in the ProfileClient will give us the time it took in the low level client (i.e. excluding plugin time execution). Measuring in the StackPlugin will give us the time it took with the plugins. Maybe it worth having both to display more data to the user!

@chr-hertel chr-hertel changed the title WIP: Extend profiler toolbar item Extend profiler toolbar item Apr 24, 2017
Copy link
Contributor

@fbourigault fbourigault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! Along with the few comments in the code, could you add a note into the changelog? Moreover I noticed something that looks weird to me in the Performance tab:
stopwatch
I can't explain why this happens yet.

$this->collectExceptionInformations($exception, $stack);
return $response;
}, function (\Exception $exception) use ($event, $stack) {
$this->collectExceptionInformations($exception, $event, $stack);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call $event->stop() here?

*/
private function getStopwatchEventName(RequestInterface $request)
{
return sprintf('%s %s', $request->getMethod(), $request->getUri()->__toString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The -->toString() is useless as %s will cast the URI as string.

@chr-hertel
Copy link
Contributor Author

@fbourigault Thanks for your review! i wasn't able to reproduce your issues exactly but i had quite similar effects caused by duplicate stopwatch event names, so i improved ProfileClient::getStopwatchEventName.
can you please test, if that fixes your problem as well?

/**
* @return int
*/
public function getDurationSum()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we call this getTotalDuration?

Copy link
Collaborator

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great job!

@fbourigault fbourigault merged commit d8a85ac into php-http:master Apr 30, 2017
@fbourigault
Copy link
Contributor

Thank you @chr-hertel.

@chr-hertel chr-hertel deleted the extend_profiler branch April 30, 2017 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants